x86: correct asm() constraints when dealing with immediate selector values
authorJan Beulich <jbeulich@suse.com>
Tue, 28 Jun 2022 15:00:29 +0000 (17:00 +0200)
committerJan Beulich <jbeulich@suse.com>
Tue, 28 Jun 2022 15:00:29 +0000 (17:00 +0200)
commit026007376e9807da94930c38500acbd62605545b
tree68a45a9635131bb97dbcef01aa0a4298b2391eb3
parent0544c4ee4b48f7e2715e69ff3e73c3d5545b0526
x86: correct asm() constraints when dealing with immediate selector values

asm() constraints need to fit both the intended insn(s) which the
respective operands are going to be used with as well as the actual kind
of value specified. "m" (alone) together with a constant, however, leads
to gcc saying

error: memory input <N> is not directly addressable

while clang complains

error: invalid lvalue in asm input for constraint 'm'

And rightly so - in order to access a memory operand, an address needs
to be specified to the insn. In some cases it might be possible for a
compiler to synthesize a memory operand holding the requested constant,
but I think any solution there would have sharp edges.

If "m" alone doesn't work with constants, it is at best pointless (and
perhaps misleading or even risky - the compiler might decide to actually
pick "m" and not try very hard to find a suitable register) to specify
it alongside "r". And indeed clang does, oddly enough despite its
objection to "m" alone. Which means there the change also improves the
generated code.

While there also switch the two operand case to using named operands.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
xen/arch/x86/cpu/amd.c
xen/arch/x86/x86_64/traps.c